1. Field of the Invention
This invention relates to software programming development and more particularly to a software debugging system for managing breakpoints.
2. Description of the Related Art
A programmer develops a software program by producing and entering source code into files using a text editor program. The computer then creates an executable program by translating the source code listing into machine code. The machine code is the rudimentary language understood by a computer. Illustratively, the foregoing software development process is accomplished by running a series of programs. These programs typically include a compiler for translating the source code into machine code and a linker to link the machine code together to form a program.
When developing computer software, it is necessary to perform a function termed “debugging”. Debugging involves testing and evaluating the software to find and correct any errors and improper logic operation. An effective debugger program is necessary for rapid and efficient development of software.
A conventional debugging system comprises a combination of computer hardware and debugger software that executes a user's program in a controlled manner. Debugging aids a user in identifying and correcting mistakes in an authored program by allowing the program to be executed in small segments. This approach is enabled primarily by two operations: step functions and breakpoints.
A “step” function permits a computer programmer to process instructions (also known as “statements”) in a computer program one-by-one, and see the results upon completion of each instruction. While the step operation provides a programmer with a large amount of information about a program during its execution, stepping through hundreds or thousands of program instructions can be extremely tedious and time consuming, and may require a programmer to step through many program instructions that are known to be error-free before a set of instructions to be analyzed are executed.
To address this difficulty, conventional debuggers utilize a breakpoint operation, which permits a computer programmer to identify, with a “breakpoint”, a precise instruction for which it is desired to halt execution of a computer program during execution. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached, and then stops execution and displays the results of the computer program to the programmer for analysis.
Some conventional debuggers support unconditional breakpoints where the execution of the program is always halted upon reaching the breakpoint. Other debuggers support conditional breakpoints that halt the execution of a program only when a predetermined value is obtained when the breakpoint is encountered.
Typically, step operations and breakpoints are used together to simplify the debugging process. Specifically, a common debugging operation is to set a breakpoint at the beginning of a desired set of instructions to be analyzed, and then begin executing the program. Once the breakpoint is reached, the program is halted, and the programmer then steps through the desired set of instructions line by line using the step operation. Consequently, a programmer is able to quickly isolate and analyze a particular set of instructions without having to step through irrelevant portions of a computer program.
One significant drawback to conventional breakpoint debugging methods is that some instructions in a computer program are executed often which may result in needless halting of the program. This problem is more pronounced in highly modular languages, such as object-oriented programming (OOP) languages, where a single general-purpose portion of a computer program might be executed in many different situations.
With an OOP language, a program is constructed from a number of “objects,” each of which includes data and/or one or more sets of instructions (often referred to as “routines” or “methods”) that define specific operations that can be performed on the data. A large number of objects may be used to build a computer program, with each object interacting with other objects in the computer program to perform desired operations.
Some general purpose objects in a computer program may support basic operations, e.g., displaying information to a user, printing information on a printer, storing or retrieving information from a database, etc. These types of objects, in particular, may have routines that are called by many different objects. Thus, placing a conventional breakpoint in a routine of such an object may result in hundreds of unwanted stoppages prior to occurrence of a desired stoppage.
Multi-user computer systems, such as mainframe computers, minicomputers, and networked computers, allow a plurality of processes, submitted by various users, to execute. These processes utilize some of the same processing hardware, program code or software objects, and data. This utilization of the same objects is especially true for a single level store system, such as an IBM eServer iSeries 400 computer. To achieve efficiencies, a single level store system will load a single copy of program code or instructions into memory, allowing multiple processes to utilize these instructions. By contrast, some other systems generally allow each process to access program code, allocating independent resources for loading this code into memory. Consequently, inserting a breakpoint into the instructions on a single level store system can mean that more than one process hits the breakpoint, burdening the processor.
The problem of unnecessary program stoppage is further compounded in multi-user systems because more than one user may be executing the same program at the same time. Other users on the system encounter delays because the system must process additional steps required when needlessly encountering a breakpoint. In order to accommodate the multi-user environment, it is generally known to implement a breakpoint as an interrupt in the computer program. Execution of the computer code thus has a software jump or a hardware interrupt to a breakpoint handling code which differentiates between users. The breakpoint handling code determines whether execution should be halted by seeing if the process setting the breakpoint also hits the breakpoint and whether any conditions are satisfied. Execution continues at the point of the breakpoint for processes not associated with the breakpoint by masking the breakpoint.
Regardless of the reason, when processes needlessly encounter breakpoints, overall system degradation can occur. Furthermore, when a computer system is executing slowly, due to system degradation, it is often difficult to debug timing-related faults.
Therefore, there is a need for a debugging system and method for processing breakpoints that does not unduly degrade the performance of a computer system.